home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Mars Digital Image Map
/
Mars Digital Image Map - Disc 6.iso
/
document
/
volinfo.txt
Wrap
Text File
|
1991-09-23
|
93KB
|
1,979 lines
CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL
RECORD_TYPE = STREAM
PRODUCT_CREATION_TIME = 1991-09-23
OBJECT = TEXT
NOTE = "Introduction to the Mars Mosaicked
Digital Image Model (MDIM) CD-ROM volumes."
END_OBJECT = TEXT
END
Mars Mosaicked Digital Image Model (MDIM)
and Digital Terrain Model (DTM)
Eric Eliason, Raymond Batson, Anthony Manley
Branch of Astrogeology
United States Geological Survey
2255 North Gemini Drive
Flagstaff, Arizona 86001
August 1, 1991
Version 1.0
CONTENTS
1 - INTRODUCTION
2 - VIKING MISSION
3 - VIKING ORBITER VISUAL IMAGING SUBSYSTEM
4 - CARTOGRAPHY AND DATA PRODUCTS
5 - DATA PREPARATION: PLANETARY DIGITAL MODELS
5.1 - PROJECTIONS
5.2 - PIXEL SIZES
6 - COMPILATION OF DIM'S
6.1 - LEVEL 1: RADIOMERIC CORRECTION
6.2 - LEVEL 2: GEOMETRIC CORRECTION
6.3 - LEVEL 3: PHOTOMETRIC CORRECTION
6.4 - LEVEL 4: CONTROLLED MOSAICKING
6.5 - DENSITY CONTRAST OF MDIM IMAGES
6.6 - MDIM IMAGE "ARTIFACTS"
7 - CONCEPT OF TILING SCHEME
8 - FILES, DIRECTORIES, AND DISK CONTENTS
8.1 - IMAGE FILE NAMING CONVENTION
8.2 - DIRECTORIES
9 - IMAGE FILE ORGANIZATION
9.1 - IMAGE LABEL AREA
9.2 - IMAGE HISTOGRAM OBJECT
9.3 - IMAGE OBJECT
10 - SOFTWARE
10.1- SOFTWARE DISCLAIMER
10.2- SOFTWARE TOOLS
11 - IMAGE INDEX
12 - GAZETTEER
13 - ACKNOWLEDGEMENTS
14 - REFERENCES
APPENDIX A - ISO VOLUME AND DIRECTORY STANDARD
APPENDIX B - SYNTACTIC RULES OF KEYWORD ASSIGNMENT STATEMENTS
APPENDIX C - KEYWORD ASSIGNMENTS FOR MDIM IMAGES
APPENDIX D - GEOMETRIC DEFINITION OF A PIXEL
APPENDIX E - SINUSODIAL EQUAL-AREA PROJECTION EQUATION
1 - INTRODUCTION
This digital image map of Mars is a cartographic extension of a
previously released set of CDROM volumes containing individual Viking
Orbiter Images (PDS volumes VO_1001, VO_1002, etc.). The data in the
latter are pristine, in the sense that they were processed only to the
extent required to view them as images. They contain the artifacts and
the radiometric, geometric, and photometric characteristics of the raw
data transmitted by the spacecraft. This new volume set, on the other
hand, contains cartographic compilations made by processing the raw
images to reduce radiometric and geometric distortions and to form
geodetically controlled Mosaicked Digital Image Models (MDIMs).
(Because the photometric processing used in this MDIM was
oversimplified, quantitative radiometric analysis on this data is not
possible.) It also contains digitized versions of an airbrushed map of
Mars as well as a listing of all IAU-approved feature names. In
addition, special geodetic and photogrammetric processing has been
performed to derive rasters of topographic data, or Digital Terrain
Models (DTMs). The latter has a format similar to that of the MDIM,
except that elevation values are used in the array instead of image
brightness values.
The MDIM CDROM collection serves two purposes. First, the image
collection serves as a data base for interactive map browser
applications. Secondly, the CDROM volume set provides a dense delivery
medium to build higher-derived cartographic image products such as
special map series and planning charts for the Mars Observer Project.
This set contains seven volumes with the following contents:
Volume 1. Vastitas Borealis Region of Mars (VO_2001): MDIMs in 373
image files covering the entire north polar region of
Mars southward from the pole to a latitude of 42.5 deg.
North. Polar Stereographic projection images of the north
pole area from 80 to 90 degrees are located in the POLAR
directory on this disk
Volume 2. Xanthe Terra Region of Mars (VO_2002): MDIMs in 412 image
files covering the region of Mars from 47.5 deg. North
latitude to 47.5 deg. South latitude, and 0 deg. longitude
to 90 deg. West longitude.
Volume 3. Amazonis Planitia Region of Mars (VO_2003): MDIMs in 412
image files covering the region of Mars from 47.5 deg.
North latitude to 47.5 deg. South latitude, and 90 deg.
West longitude to 180 deg. West longitude.
Volume 4. Elysium Planitia Region of Mars (VO_2004): MDIMs in 412
image files covering the region of Mars from 47.5 deg.
North latitude to 47.5 deg. South latitude, and 180 deg.
West longitude to 270 deg. West longitude.
Volume 5. Arabia Terra Region of Mars (VO_2005): MDIMs in 412 image
files covering the region of Mars from 47.5 deg. North
latitude to 47.5 deg. South latitude, and 270 deg. West
longitude to 0 deg. West longitude.
Volume 6. Planum Australe Region of Mars (VO_2006): MDIMs in 373
image files covering the entire South polar region of
Mars northward from the pole to a latitude of 42.5 South
latitude. Polar Stereographic projection images of the south
pole area from 80 to 90 degrees are located in the POLAR
directory on this disk
Volume 7. Digital Topographic Map of Mars (VO_2007): MDIMs of the
entire planet at 1/64, 1/16, DTMs of the entire planet at
1/64, 1/16, and the digitized airbrush map of Mars at 1/16
and 1/4 deg./pixel.
Each of the first six volumes contains MDIMs of the areas specified at
resolutions of 1/256 deg./pixel (231m) and at 1/64 deg./pixel (943m).
Volumes 1 and 6 also contain MDIM coverage of the entire planet at 1/16
deg./pixel (3.69 km). The six volumes also include a digitized airbrush
map of the entire planet at 1/16 deg./pixel (3.69 km) and at
1/4 deg./pixel. The Sinusoidal Equal-Area Projection, is used as the
map projection for this image collection. For a detailed description of
the Sinusoidal projection and use of the cartographic keywords found in
the image labels, refer to Appendix E of this document.
The tiling layout of the 1/64 deg./pixel digital models is the same on
the first six volumes. Note that the 1/64 deg./pixel MDIM, segments of
which appear in Volumes 1 through 6, is duplicated in its entirety on
Volume 7. All of the resolution compressions were done by averaging,
not by subsampling. A gazetteer of IAU-approved feature names,
referenced by latitude/longitude coordinates is included as a table file
on each of the seven volumes.
2 - VIKING MISSION
The Viking Mission consisted of four spacecraft: two identical orbiters
and two identical landers. During cruise from Earth to Mars the landers
were attached to the orbiters. Thirteen science teams had experiments
on these spacecraft. The major scientific objective of the mission was
to search for life on Mars. Several experiments on the landers were
designed to address this objective. In addition, some of the
experiments on the orbiters and landers focused on the study of the
composition and physical properties of the atmosphere, the distribution
of water vapor, and global and local meteorology. Other experiments
investigated the composition and physical properties of the surface and
the geologic history of Mars. Data on the seismicity of Mars and its
gravity field were also acquired to study the internal structure of Mars
[1, 2].
One of the Orbiter experiments was the Visual Imaging Subsystem (VIS),
which acquired the images that comprise the Mars MDIM. The imaging
system is briefly described in the next section. The first objective of
the VIS experiment was to characterize potential landing sites in
support of site selection. Additional objectives were to study the
photometric and colorimetric properties of the surface; to study various
geological features that were discovered by Mariner 9 in order to better
understand the geological history of Mars; to study the dynamics of the
atmosphere; and to monitor the surface for changes.
The Viking Orbiter spacecraft operated in orbit around Mars from 1976
until 1980. The overall Viking mission was divided into a number of
mission phases with specific objectives. The time from orbital
insertion in June 1974 until November 1976 is known as the Primary
Mission. The main objective of the Orbiter instruments was to collect
data in support of landing site selection. The spacecraft orbital
characteristics were chosen so that the Orbiters could serve as relay
stations for communications between the Landers and Earth. In addition,
the Orbiter imaging systems imaged all of the terrains on Mars,
collected some color and stereo images, and made observations of Phobos
and Deimos. The Viking Extended Mission took place from November 1976
through May 1978, and the Viking Continuation Mission took place from
May 1978 through February 1979. During these periods the Orbiters were
not always required as relay stations with the Landers. Some of the
image sequences acquired by the VIS experiment include systematic medium
and high resolution coverage of large portions of the surface, stereo
images, observations of Phobos and Deimos, color images of the
equatorial regions, observations of the polar regions, and monitoring
dust storm activity. The final phase of the Viking Mission was the
Survey Mission from July 1979 until July 1980. During the Survey
Mission only Viking Orbiter 1 operated since Viking Orbiter 2 had lost
its attitude control gas through a series of leaks. The Orbiter 1 image
coverage during the Survey Mission was designed to obtain contiguous
high resolution coverage of the Martian cratered terrain. One reason
for acquiring these data was to help select landing sites on Mars for
future missions.
3 - VIKING ORBITER VISUAL IMAGING SUBSYSTEM
Each Viking Orbiter was equipped with two identical vidicon cameras,
called the Visual Imaging Subsystem (VIS) [3, 4, 5]. Each VIS camera
consisted of a telescope, a slow scan vidicon, a filter wheel, and
associated electronics. The angular field of view of the camera as
defined by the reseau pattern was 1.51 by 1.69 degrees. The ground area
covered by an image varies as a function of spacecraft altitude and
emission angle. A digital image was generated by scanning the vidicon
face plate. The signal at each location (pixel) was digitized as a
7-bit number (i.e., within the range of 0 to 127). The EDR image data
were converted to 8-bit numbers by multiplying the original 7-bit
numbers by 2. Thus, the least significant bit of each pixel in an EDR
image is zero, except for interpolated pixels or pixels with corrupted
values. A full-resolution, Viking Orbiter image consists of an array of
1056 lines with 1204 samples per line. There are only 1182 valid
samples in each line. The extra 22 samples in each line consist of dark
bands on the left and right edges of each image, produced by an opaque
mask located at the front of the vidicon. Each dark band is
approximately 11 samples wide, although the exact width varies from
image to image.
Each VIS camera contained a filter wheel with five color filters (blue,
minus blue, violet, green, and red) and a clear position, i.e., no
filter. The filter half power bandwidths are approximately: blue from
0.35 to 0.53 micrometers; minus-blue from 0.48 to 0.70 micrometers;
violet from 0.35 to 0.47 micrometers; clear from 0.35 to 0.70
micrometers; green from 0.50 to 0.60 micrometers; and red from 0.55 to
0.70 micrometers. Multiple images of the same areas were occasionally
acquired using violet, green, and red filters to form color images after
processing on Earth. Color image reconstruction from Viking imaging
requires radiometric and geometric corrections, and co-registration of
the images that make up the color set.
4 - CARTOGRAPHY AND DATA PRODUCTS
The global MDIM of Viking Orbiter images of Mars was compiled according
to the plan described by Batson [6, 7, 8, 9]. The images have had
improved radiometric and geometric enhancements over the images used in
the published 1:2,000,000-scale controlled photomosaic map series
published by USGS.
The MDIM is tied to a refined topographic control net for Mars [10] with
a published standard error of this net of about 5 km for the control
base, which represents 20 pixels at 1/256 deg./pixel in the MDIM.
Discrepancies between adjacent frames are far less than 20 pixels over
most, but not all, of the planet. We attempted to distribute the error
so that it was not obtrusive in the mosaics, but this was not possible
in some areas. The error can be attributed to a lack of precise
knowledge of the spacecraft location at the time each image was taken
and to parallax in oblique images of rugged terrain. Camera locations
can be derived only by tracking the spacecraft continuously and
precisely during its active lifetime, which was not always done for
Viking Orbiters 1 and 2. Given assumed camera positions, camera
orientations were derived by reducing to their minima the discrepancies
between images in overlapping frames and the control net.
First-order photometric corrections were also performed and contrast
ranges were normalized based on solar illumination geometry. This
processing greatly reduces tonal discrepancies between individual images
even when illumination differences are extreme, but it is a form of
spatial filtration and results in the loss of regional albedo
information.
5 - DATA PREPARATION: PLANETARY DIGITAL MODELS
Digital mosaics have in the past been compiled primarily as elegant
demonstrations of a costly alternative to manual compilations. They
have generally been special products designed to serve specialized
purposes and until recently were not affordable as primary standard
products. The intent of the digital planetary mapping program is to
develop a unified system, consisting of a single digital format for all
planetary cartographic databases. The relations between digital
map-storage formats and map projection and image resolution are
therefore fundamental considerations in the design of the system.
5.1 - PROJECTIONS
The simplest form of a digital model (DM) is one in which each image
element's value is stored in a "bin" (pixel) labeled in terms of
latitude and longitude. For computer work, it is only necessary that
each bin be readily accessible. In compiling and describing DM's,
however, it is useful to discuss a digital array in terms of map
projections. The simplest projection is one in which each image line,
or row of bins, is a parallel of latitude and each column of samples, or
bins, is a meridian. This presentation was termed a "Simple Cylindrical"
or "Square" projection by Clark [11]. Its simplicity is appealing, even
though the higher latitudes are oversampled (e.g., the pole of a planet,
in reality, is a point, but is represented digitally by an image line
with as many samples as that for the equator, all with the same value).
Several planetary consortia, consisting of geological, geochemical, and
geophysical databases in this format, have used this format for several
years for the Moon, Mars, Venus, and the Galilean satellites [12, 13,
14, 15]. The total storage required for this kind of array is only about
60% more than if each element represented the same size area on the
planet, and is therefore not prohibitive. However, this projection does
present an operational problem, in that a Simple Cylindrical projection
of a single spacecraft image containing the north or south pole has too
many pixels in an image line to manage easily during DM compilation. As
a result, the Sinusoidal Equal-Area projection [16] was selected for
compiling planetary DM's. The conversions between Simple Cylindrical
and Sinusoidal Equal-Area geometry are so computationally trivial that
the two formats are nearly twins.
A Sinusoidal Equal-Area projection is one in which each parallel of
latitude is an image line, and the length of each line is compressed by
the cosine of its latitude. For a detailed description of the Sinusoidal
projection and use of the cartographic keywords found in the image
labels, refer to Appendix E of this document. The Sinusoidal projection
has the simplicity of the Simple Cylindrical projection so far as
indexing (rows and columns are still parallels along meridians), but
compilation is much more efficient in the Sinusoidal Equal-Area because
the projection does not have mathematical peculiarities at the poles.
However, viewing distortion becomes severe with distance from the
central meridian in the sinusoidal presentation. This is a problem only
for visual examination of DIM images; it is not relevant to the
integrity of the database. By simply sliding image lines parallel to
one another, the central meridian can be rapidly shifted; this allows an
undistorted view of a selected region without geometrically resampling
the image. Segments of a DIM can therefore be displayed with a local
central meridian, although the poles themselves must be transformed to a
polar projection.
5.2 - PIXEL SIZES
The resolution of digital images is often given in terms of pixel
dimensions in meters or kilometers on the surface of a target. However,
Mars DM's on this CDROM are encoded so that the number of lines (which
are also parallels of latitude) in a global DM is an integer. It is
therefore more convenient to specify DM resolution in terms of
planetocentric degrees than in linear units. The size of pixels in DM's
is therefore specified as some negative power of two (1/4, 1/8, 1/16 . .
. 1/256, etc.) degrees per pixel. Resolutions intermediate to these
values are not used, so that databases can be registered in scale simply
by successively doubling or halving the pixel sizes by subsampling or
averaging, but without resampling.
Selected segments of DIMs may be written as photographic prints or
published as maps in the traditional format. Table 1 shows metric
equivalents of pixel sizes for each solar system body currently included
in NASA's mapping plans [17]. Table 1 shows equivalents of digital model
resolutions, in kilometers per pixel. Mean radii are given for
non-spherical bodies.
TABLE 1. - METRIC EQUIVALENTS OF PIXEL SIZES FOR SOLAR SYSTEM BODIES
--------------------------------------------------------------------
| |Radius| Digital scale (deg/pixel) |
|Planet | (km) | 1/16| 1/32| 1/64| 1/128| 1/256| 1/512|1/1024|
|_________|______|______|______|______|______|______|______|______|
| | | | | | | | | |
|Mercury | 2439| 2.660| 1.330| .665| .333| | | |
| | | | | | | | | |
|Venus | 6052| 6.602| 3.301| 1.650| .825| .413| .206| .103|
| | | | | | | | | |
|Moon | 1738| 1.896| .948| .474| .237| .118| .059| |
| | | | | | | | | |
|Mars | 3385| 3.692| 1.846| .923| .462| .231| .115| .058|
|Phobos | 11| .012| | | | | | |
|Deimos | 6| .007| | | | | | |
| | | | | | | | | |
|Io | 1821| 1.986| .993| .497| .248| .124| .062| |
|Europa | 1565| 1.707| .854| .427| .213| .107| .053| |
|Ganymede | 2634| 2.873| 1.437| .718| .359| .180| .090| |
|Callisto | 2403| 2.621| 1.311| .655| .328| .164| .082| |
| | | | | | | | | |
|Mimas | 199| .217| | | | | | |
|Enceladus| 249| .272| | | | | | |
|Tethys | 523| .571| | | | | | |
|Dione | 560| .611| | | | | | |
|Rhea | 764| .833| .417| | | | | |
|Iapetus | 718| .783| | | | | | |
| | | | | | | | | |
|Miranda | 236| .257| | | | | | |
|Ariel | 579| .632| | | | | | |
|Umbriel | 585| .638| | | | | | |
|Titania | 789| .861| | | | | | |
|Oberon | 761| .830| | | | | | |
| | | | | | | | | |
|Triton | 1353| 1.476| .738| .369| .184| .092| | |
|_________|______|______|______|______|______|______|______|______|
6 - COMPILATION OF DIM'S
The Mars Digital image models on this CDROM are compiled and archived in
four stages or "levels", beginning with raw images. All of the
corrections made during these stages have some level of uncertainty, so
the processing sequence is designed to progress from corrections with
the highest probability of accuracy to the lowest, and intermediate
stages are preserved for future analytical use. Image processing
software exists to perform the various stages of image correction and
enhancement [18, 19].
6.1 - LEVEL 1: RADIOMETRIC CORRECTION
Level 1 processing includes removal of electronic shading, which is
inherent in the imaging system, and artifacts such as minute dust specks
on the vidicon tube, microphonic noise introduced by operation of other
instruments on the spacecraft during imaging sequences, and data
drop-outs and spikes [15]. Reseau marks are also located and removed
during this stage; their precise locations are recorded for use during
later geometric processing. A digital image label is created,
containing the reseau-mark locations, geodetic control point and image
tie-point locations, and a computed camera orientation matrix that will
project the frame to a best-fit shape and position in a mosaic.
Level 1 images have better resolution than those produced at any
subsequent processing level. This is because they have not been
resampled for geometric correction and projection; some loss of
information is inevitable in any resampling, because the density values
of multiple pixels and/or fractional pixels must be averaged to form new
pixels in the output array. Photographic copies of Level 1 images, with
spatial filter enhancement, are therefore the more useful photographic
materials for visual interpretation.
6.2 - LEVEL 2: GEOMETRIC CORRECTION
Level 2 processing includes removal of camera distortions and
transformation from image to map coordinates in DM format according to
parameters derived at the end of the Level 1 processing phase [20]. The
resolution of each frame is preserved to some extent by oversampling in
the output array; that is, by selecting a resolution step that results
in an image with more lines and samples than the original image.
Distortion corrections are based on preflight calibration of the reseau.
Image transformation is based on camera orientation matrices derived by
photogrammetric triangulation [21] modified as required for a best fit
with adjacent images. On those images where matrices are not available,
they are derived by matching corresponding points with images that have
matrices.
6.3 - LEVEL 3: PHOTOMETRIC CORRECTION
At level 3 processing apparent inconsistencies in surface brightness
caused by variation in illumination geometry and by atmospheric effects
are treated. Atmospheric scattering is a significant consideration on
Mars. Different materials on any planet have different light-reflecting
properties. Other photometric corrections are effective only to the
extent that all geometric parameters can be modeled. In general, local
topography is not included in the model (i.e., the surface model used is
flat). Illumination geometry at each pixel, however, certainly depends
on local topography; unless the topographic slope within a pixel is
accurately known and compensated, the photometric correction cannot be
perfect. All of these conditions are so complex that photometric
correction of planetary images is likely to be only approximate for some
time into the foreseeable future, although research into the effects and
prototype examples of full three-dimensional treatment are now being
pursued. An obvious example of the complexity of the problem would
consist of a pair of images of the same landform illuminated from
opposite directions. Only an extremely complex algorithm could
accurately modify the shading in one of the images to match that of the
other. No algorithm could restore detail lost in shadow.
The photometric processing used in this MDIM was necessarily
oversimplified, and incorporates spatial filtration that has the effect
of subduing regional albedo markings. Further, quantitative radiometric
analysis cannot be performed on the MDIM image collection.
Prior to mosaicking, each of the digital images was first filtered to
suppress regional scale albedo patterns larger than about one degree on
the planet. This was done by applying a 251x251 high-pass boxcar filter
[27] to each 16-bit integer image after geometric transformation. The
high-pass filter was performed by convolving each image with a 251x251
boxcar of unit weight, subtracting this smoothed image from the original
image and adding it to 16384. The value 16384 was added in order to
keep pixel values always greater than zero.
Each image was then linearly stretched and converted to 8-bit unsigned
integer format. The stretch parameters were chosen to normalize the
images so that features of the same relief in different images would
have the same contrast although images were acquired with different
incidence and emission angles and through different filters. The MINIMA
(mapped to 0 in 8-bit unsigned integer space) and MAXIMA (mapped to 255
in 8-bit space) for the linear stretch were computed as follows:
MINIMA = 16384 - DELTA
MAXIMA = 16384 + DELTA
DELTA= (Rf*EXP(-TAU*(MUc+MUoc))*SIN(Ic))/(EXP(-TAU*(MUs+MUos))*Sin(Is))
where MUc and MUoc are the cosines of the emission and incidence angles
at the image center; TAU is the optical depth of the atmosphere; MUs and
MUos are the emission and incidence angles the images are to be
normalized to; and Rf is a scaling coefficient dependent on the spectral
bandpass. The following were used for the entire series of images:
MUs=0; MUos=45 degrees; TAU=0.3; Rf=1275 for red; Rf=815 for
minus-blue, green, and clear; and Rf=435 for violet. If the value of
MUoc was greater than 83 degrees, it was set to 83 degrees.
Finally, a seam-removal technique was used in the mosaicking procedure.
First the filtered and stretched images were mosaicked. This mosaic was
then filtered with a 51x51 low-pass filter (convolved with a 51x51
boxcar of unit weight). A 51x51 high-pass filter was next applied to
each individual image that makes up the mosaic. Finally, this
mosaic of high-pass filtered images was added to the low-pass filtered
mosaic.
6.4 - LEVEL 4: CONTROLLED MOSAICKING
Compilation of an accurate digital mosaic (MDIM) of the entire surface
of a planet is the final stage in the construction of a DIM. The MDIM
is a digital image of the planet, with uniform resolution throughout.
The resolution of level 2 images used in the compilation is compressed
or expanded to match that of the MDIM.
6.5 - DENSITY CONTRAST OF MDIM IMAGES
MDIM's data number (DN) dynamic range is designed so that every image
file will match in contrast with any of its neighboring files. This
allows image files to be mosaicked together without having obvious
contrast boundaries in the mosaic. The highest contrast on Mars is in
the polar region and the image density histograms of these areas fill
the full dynamic range 0 to 255. There are image files that cover
low-contrast areas on the planet and the density histograms of these
images will fill only a limited part of the full 0 to 255 range.
When viewing low-contrast images on a display device, the image will
look very bland unless a contrast stretch is applied to the image
values. For convenience of image display applications, the MDIM files
have an object containing the image histogram in order to facilitate the
rapid display of an image with optimum contrast. An image display
application could extract the image histogram from the file, use it to
determine an optimum contrast stretch, and then load the display's DN
look-up table to perform the contrast stretch.
6.6 - MDIM IMAGE "ARTIFACTS"
"Perfect" cartographic products do not exist--all compilations are
compromises at some level and the MDIM digital cartographic products are
no exception. Various artifacts exist in the MDIM products which require
some explanation.
The original Viking EDR images were mapped to the Sinusoidal projection
using the simplest approach of resampling know as "nearest neighbor"
interpolation. In this approach, the data value of the pixel in the
input irregular image closest to the location of the pixel in the
desired output image is used for the value of the output pixel. The
intensity values resulting from this interpolation scheme correspond to
true pixel locations that can be as much as the square root of two
spacing in error. (A comparison of resampling interpolation schemes are
described in Bernstein [22].)
The minimum longitude limit of a file (keyword MINIMUM_LONGITUDE) does
not always end on an even longitude boundary. This was intentional.
There is an unresolved issue on how the ISO/CDROM standard defines the
format of fixed length record files of odd size. To avoid this issue,
the minimum longitude limit of the file was set to always insure there
were an even number of pixels in the line length.
Artifacts in the image data exist due to poorly interpolated reseau and
improperly removed random noise and vidicon camera blemishes.
7 - CONCEPT OF THE TILING SCHEME
Most MDIMs are far too large to be managed conveniently as single files.
They must therefore be segmented by some scheme analogous to the
segmentation of a map series into quadrangles. Mars has been segmented
into 1964 quadrangles for high-resolution mapping at a scale of
1:500,000; this scheme has been selected for tiling the MDIM because it
results in tiles of reasonably convenient size, and because it allows
easy cross reference between the MDIM and published paper maps. The
tiles have dimensions of 5 deg. latitude by 5 deg. longitude at the
equator. The longitude dimension is modified to account for the
convergence of meridians on a globe, beginning at 47.5 deg. latitude, so
that each tile in the MDIM retains roughly the same area.
Just as published maps are indexed by the latitude/longitude of their
center points (truncated to the nearest integer degree to simplify the
indexing), the labels of the files in the MDIM refer to the
latitude/longitude of the center of the tile. Thus, the tile (MDIM
file) labelled MI05N312 is centered on a point 5 deg. north of the
equator and at a latitude of 312 deg. W.
Each tile has its own central meridian in order to minimize the
geometric distortion (shearing) of the data within the tile. Thus, each
tile, with the exception of the tiles that make up the poles, can be
independently displayed and its view will be quite reasonable with
virtually no geometric distortion due to the nature of the projection.
Thus, craters remain round rather than being oblong. With each tile
having its own central meridian, simple display software can display a
tile (or sub-area of a tile) with virtually no geometric distortion in
the area of interest.
One of the nice advantages of the Sinusoidal Equal-Area projection is
the simple process for changing the central meridian of the projection.
The central meridian is changed simply by sliding image lines parallel
to one another (assuming nearest-neighbor interpolation). For a computer
algorithm to convert an MDIM tile to a new central meridian, the
algorithm need only calculate a starting offset (where to put the first
sample of the input line) and simply move the pixels from the input
buffer to the output buffer starting at the calculated offset. For
example, if a feature of interest existed on a boundary between two
tiles, it would be relatively simple to develop a program that would
read the two tiles into memory, create an output memory array with a new
central meridian equal to the boundary longitude between the two tiles,
and then copy the input tile lines to the output tile lines with a
calculated offset value for each line.
8 - FILES, DIRECTORIES, AND DISK CONTENTS
8.1 - IMAGE FILE NAMING CONVENTION
Each image file has a unique name that is constructed according to the
type of image file, resolution, and its central latitude and longitude.
Because only eight characters are available as a file name, a highly
compressed notation is used. The general form of an image file name is
'vwxxyzzz.IMG'. In this construct the 'v' field represents the type of
image data in the file and it has three possible values: 'M' represents
a MDIM image, 'T' represents a DTM image, and 'S' represents a shaded
relief airbrush image. The 'w' field represents the resolution of the
image file. In this field an alphabetic character is used to represent
the scale: 'A' = 1/1 degrees/pixel, 'B' = 1/2, 'C' = 1/4, 'D' = 1/8, 'E'
= 1/16, etc. For this volume set only the characters 'C' (1/4
degree/pixel), 'E' (1/16 degree/pixel), 'G' (1/64 degree/pixel), and 'I'
(1/256 degree/pixel) are used. The 'xx' field is constructed from the
central latitude of the image file. The central latitude is rounded down
to the nearest whole integer of latitude. The 'y' field contains the
value of 'N' for north latitude files, and 'S' for south latitude files.
Finally, the 'zzz' field is constructed from the central longitude of
the image file. The central longitude is rounded down to the nearest
whole integer of longitude. The '.IMG' extension name is a PDS standard
indicating the file is an image file. MI00N090.IMG is an example file
name. It is an MDIM image, has a resolution of 1/256 degree/pixel, a
center latitude at the equator, and a center longitude at 90 degrees.
Table 2 summarizes the file naming convention for image files.
TABLE 2. - IMAGE FILE NAME CONVENTION
-------------------------------------
General Form of Image File Names - vwxxyzzz.IMG
where:
v = Type of image file
M - Mars Digital Image Map
T - Mars Digital Topographic Model
S - Shaded Relief Airbrush Map
w = Resolution code for image file
C - 1/4 degrees/pixel
E - 1/16 degrees/pixel
G - 1/64 degrees/pixel
I - 1/256 degrees/pixel
xx = Central latitude value rounded
down to nearest whole latitude
y = North or South latitude
N - North latitude
S - South latitude
zzz = Central longitude value rounded
down to nearest whole longitude
-------------------------------------------
8.2 - DIRECTORIES
The volume and directory structure of this CD-ROM conforms to the level-1
standard specified by the International Standards Organization (ISO).
This standard is also known as the ISO-9660 standard. The ISO standard
was used so that the disks can be accessed on a wide variety of computer
systems. Information on the ISO-9660 CD-ROM standard is provided in
Appendix A of this document.
The Image files are subdivided into directories based on the type of
image file (MDIM, DTM, shaded relief airbrush), the resolution of the
image file, and for 1/256 and 1/64 degree/pixel image files the center
latitude of the image. For 1/4 and 1/16 degree/pixel images the first
two characters of a file name followed by six 'X' characters make up the
directory name. For example, all of the 1/16 degree/pixel MDIM images
are located in the directory MEXXXXXX (Volumes 1 and 6 only). For 1/256
and 1/64 degree/pixel images the first five characters of a file name
followed by three 'X' characters make up the directory name. For
example, all of the 1/256 degree/pixel images with center latitude 45
degrees north are located in the directory MI45NXXX. Volumes 1 and 6
contain a special directory called POLAR which contains Polar
Stereographic projection images from 80 to 90 degrees latitude.
The MDIM images, Shaded relief airbrush images, DTM image files (volume
7 only), supplemental files, documentation, and software are located in
separate directories. Table 3 shows the contents of the 10 directories
common to all seven volumes: 1) the root directory is the primary
directory on the disk; 2) the DOCUMENT directory contains documentation
files; 3) the GAZETTER directory contains the gazetteer table and
supplemental files; 4) the INDEX directory contains the image index
table; 5) the LABEL directory contains ancillary PDS label files; 6) the
SOFTWARE directory contains supporting software for the MDIM image
files; 7) the SCXXXXXX directory contains the 1/4 degree resolution
shaded relief airbrush image; 8) the SEXXXXXX directory contains the
shaded relief airbrush map at 1/16 degree resolution; and 9) the
MEXXXXXX directory contains the 1/16 degree resolution MDIM images
TABLE 3. - DIRECTORY CONTENTS OF COMMON DIRECTORIES
---------------------------------------------------
root directory
AAREADME.TXT - Introduction to this CDROM volume
VOLDESC.SFD - Volume descriptor label
DOCUMENT directory
VOLINFO.TXT - Documentation for the MDIM volumes
GAZETTER directory
GAZETTER.TXT - Gazetteer documentation
GAZETTER.LBL - PDS labels for the Gazetteer table
GAZETTER.TAB - Gazetteer table for Mars
GAZINFO.TXT - Information on Gazetter table
GAZETTER.DBF - DBASE structure file for Gazetteer table
WPMACRO.TXT - How do use the Word Perfect Macros
*.WPM - Word Perfect macros for conversion of
diacritical marks to Word Perfect format
INDEX directory
IMGINDEX.LBL - PDS labels for the image index table
IMGINDEX.TAB - Image index table
INDXINFO.TXT - Information on index table
IMGINDEX.DBF - DBASE structure file for index table
LABEL directory
DSMAPDIM.LBL - Ancillary label for the data set map
projection object.
SOFTWARE directory
MAC subdirectory - Macintosh display software
PC subdirectory - IBM/PC display software
SUN subdirectory - SUN Sparcstation display software
VAX subdirectory - VAX/VMS Workstation display software
SCXXXXXX directory
SC00N000.IMG - Shaded Relief Airbrush image file at 1/4
degrees per pixel containing 1440
samples and 720 lines.
SEXXXXXX directory
*.IMG - Shaded Relief Airbrush image files at 1/16
MEXXXXXX directory
*.IMG - MDIM image files at 1/16 degrees per pixel
9 - IMAGE FILE ORGANIZATION
The record structure of the MDIM, Shaded Relief Airbrush, and DTM image
files is a fixed-length format (see Appendix A for a description of
fixed-length record files). There are three areas that make up the image
file: the image label, the image histogram object, and the image object.
9.1 - IMAGE LABEL AREA
The label area of a image file contains descriptive information about
the image. The label consists of keyword statements that conform to
version 2 of the Object Description Language (ODL) developed by NASA's
PDS project [23, 24]. There are three types of ODL statements within a
label: structural statements, keyword assignment statements, and pointer
statements.
Structural statements provide a shell around keyword assignment
statements to delineate which data object the assignment statements are
describing. The structural statements are:
1) OBJECT = object_name
2) END_OBJECT
3) END
The OBJECT statement begins the description of a particular data object
and the END_OBJECT statement signals the end of the object's
description. All keyword assignment statements between an OBJECT and
its corresponding END_OBJECT statement describe the particular object
named in the OBJECT statement. The END statement terminates a label.
A keyword assignment statement contains the name of an attribute and the
value of that attribute. Keyword assignment statements are described in
more detail in Appendix B of this document. These statements have the
following format:
name = value
Values of keyword assignment statements can be numeric values, literals,
and text strings.
Pointer statements are a special class of keyword assignment statements.
These pointers are expressed in the ODL using the following notation:
^object_name = location
If the object is in the same file as the label, the location of the
object is given as an integer representing the starting record number of
the object, measured from the beginning of the file. The first label
record in a file is record 1. Pointers are useful for describing the
location of individual components of a data object. Pointer statements
are also used for pointing to data or label information stored in
separate files. An example of a detached label (i.e., label information
stored in a separate file) is shown below: By convention, detached
labels are found in the LABEL directory.
^STRUCTURE = 'logical_file_name'
The value of 'logical_file_name' is the name of the detached label file
containing the description.
The keyword statements in the label are packed into the fixed-length
records that make up the keyword label area. Each keyword statement is
terminated by a carriage-return and line-feed character sequence. An
example of a MDIM image label is shown in table 5. Descriptions of the
keywords used in the MDIM label are found in Appendix C.
TABLE 5. - EXAMPLE OF MDIM IMAGE LABEL
--------------------------------------
CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL
/* FILE FORMAT AND LENGTH */
RECORD_TYPE = FIXED_LENGTH
RECORD_BYTES = 1184
FILE_RECORDS = 1283
LABEL_RECORDS = 2
/* POINTERS TO START RECORDS OF OBJECTS IN FILE */
^IMAGE_HISTOGRAM = 3
^IMAGE = 4
/* IMAGE DESCRIPTION */
DATA_SET_ID = "VO1/VO2-M-VIS-5-DIM-V1.0"
SPACECRAFT_NAME = {VIKING_ORBITER_1, VIKING_ORBITER_2}
TARGET_NAME = MARS
IMAGE_ID = MI65N005
SOURCE_IMAGE_ID = {"793A03", "823A12", "669B17", "672B32",
"672B55", "672B57", "672B58", "672B60", "672B61", "672B62",
"672B83"}
INSTRUMENT_NAME = {VISUAL_IMAGING_SUBSYSTEM_CAMERA_A,
VISUAL_IMAGING_SUBSYSTEM_CAMERA_B}
NOTE = "MARS DIGITAL IMAGE MAP, 1/256 DEG./PIXEL,
CENTER LAT,LON 65.00, 5.000 "
/* DESCRIPTION OF OBJECTS CONTAINED IN FILE */
OBJECT = IMAGE_HISTOGRAM
ITEMS = 256
ITEM_TYPE = VAX_INTEGER
ITEM_BITS = 32
END_OBJECT = IMAGE_HISTOGRAM
OBJECT = IMAGE
LINES = 1280
LINE_SAMPLES = 1184
SAMPLE_TYPE = UNSIGNED_INTEGER
SAMPLE_BITS = 8
SAMPLE_BIT_MASK = 2#11111111#
CHECKSUM = 123456789
END_OBJECT = IMAGE
OBJECT = IMAGE_MAP_PROJECTION_CATALOG
^DATA_SET_MAP_PROJECTION_CATALOG = "DSMAPDIM.LBL"
MAP_PROJECTION_TYPE = SINUSOIDAL
MAP_RESOLUTION = 256<PIXEL/DEG>
MAP_SCALE = 0.231352<KM/PIXEL>
MAXIMUM_LATITUDE = 67.50000
MINIMUM_LATITUDE = 62.50000
MAXIMUM_LONGITUDE = 10.00000
MINIMUM_LONGITUDE = -0.01627
X_AXIS_PROJECTION_OFFSET = -17280.000
Y_AXIS_PROJECTION_OFFSET = -591.038
A_AXIS_RADIUS = 3393.40
B_AXIS_RADIUS = 3393.40
C_AXIS_RADIUS = 3375.73
FIRST_STANDARD_PARALLEL = "N/A"
SECOND_STANDARD_PARALLEL = "N/A"
POSITIVE_LONGITUDE_DIRECTION = WEST
CENTER_LATITUDE = 0.00000
CENTER_LONGITUDE = 5.00000
REFERENCE_LATITUDE = "N/A"
REFERENCE_LONGITUDE = "N/A"
X_AXIS_FIRST_PIXEL = 1
Y_AXIS_FIRST_PIXEL = 1
X_AXIS_LAST_PIXEL = 1280
Y_AXIS_LAST_PIXEL = 1184
MAP_PROJECTION_ROTATION = "N/A"
END_OBJECT = IMAGE_MAP_PROJECTION_CATALOG
END
9.2 - IMAGE HISTOGRAM OBJECT
The first object after the label in an MDIM image file is the histogram
of the image. The Image Histogram Object begins at the record specified
by the ^IMAGE_HISTOGRAM pointer keyword. (Note, the first record in the
file is defined as record 6.) The number of fixed-length records that
make up the image histogram object can be determined by subtracting the
value of the ^IMAGE pointer keyword from the ^IMAGE_HISTOGRAM pointer
keyword value. These records, when concatenated together, contain the
256 elements of the image histogram with each element occupying four
bytes. Each element is a 32-bit VAX integer [25]. The first element of
the histogram contains the count of pixels in the image with the
brightness value 0. The last element contains the count of pixels in the
image with brightness value 255.
9.3 - IMAGE OBJECT
The second object in the MDIM image file contains the image data. The
image starts at the record specified by the ^IMAGE keyword. The number
of records that make up the image is specified by the LINES keyword
value. Each image line is stored in a separate fixed-length record. Each
sample is an 8-bit unsigned integer as described by the SAMPLE_BITS and
the SAMPLE_TYPE keywords in the label. For DTM data, each sample is a
16-bit signed integer. The LINE_SAMPLES keyword describes the number of
elements in each image line.
10 - SOFTWARE
10.1 - SOFTWARE DISCLAIMER
Although the software contained on the MDIM CDROMs have been used and
tested, no warranty, expressed or implied, is made by NASA, the Jet
Propulsion Laboratory (JPL), or the United States Geological Survey
(USGS) as to the accuracy and functioning of the software and related
materials, and no responsibility is assumed by NASA, JPL, or the USGS.
10.2 - SOFTWARE TOOLS
Software is provided on the MDIM CDROMs to facilitate access to the
image files. These files allow simple display capability of the
individual image tiles. Software is provided for four hardware
platforms: Apple Macintosh, IBM/PC, SUN Sparcstation, and VAX/VMS
workstation systems. The software is located in subdirectories within
the SOFTWARE directory. The subdirectories MAC (Macintosh software), PC
(IBM/PC software), SUN (SUN Sparcstation), and VAX (VAX/VMS workstation)
will be found. Within each subdirectory is located a file called
SOFTINFO.TXT which describes how to use the software.
11 - IMAGE INDEX
Each CDROM in the MDIM volume set contains an image index file
(IMGINDEX.TAB) with catalog information about all MDIM image files in
the collection. The image index file and it's associated PDS label file
(IMGINDEX.LAB) are located in the INDEX directory. The catalog
information in the index table includes the file names, CDROM volumes
containing the MDIM image files, and mapping parameter information.
The image index file has fixed-length records of length 512 bytes in
ASCII character representation. Each record (row in the table) contains
the information for a single MDIM image file.
Table 6 describes the contents of the image index file located in the
INDEX directory. All fields are in ASCII character format. The image
index files are formatted to allow automatic data entry programs to
access the data for entry into an existing data base system. The
non-numeric fields are enclosed by double-quote characters. All fields
are delimited by commas. The last two bytes in a record are
carriage-control and line-feed characters. Table 6 gives the starting
and ending byte positions of each field in the image index. These byte
positions specify the actual fields and do not include the double-quote
marks and commas that separate the fields.
TABLE 6 - FORMAT OF IMAGE INDEX FILE
------------------------------------
Byte Positions Description
----------------------------------------------------------------------
2 - 23 FILE_NAME: the fully qualified CDROM file name for the
image file. The format of the directory name
specification is the VAX/VMS directory format, with
brackets indicating the directory hierarchy. Users on
other systems will need to convert the directory names
to the operating system formats.
26 - 35 MAXIMUM_LATITUDE: the Maximum latitude in the image file.
Latitude ranges from +90.0 degrees for the north pole
to -90.0 degrees for the south pole.
37 - 46 MINIMUM_LATITUDE: the minimum latitude in the image file.
48 - 58 MAXIMUM_LONGITUDE: the maximum longitude in the image
file.
Longitude ranges from +180.0 to -180 degrees.
60 - 70 MINIMUM_LONGITUDE: the minimum longitude in the image
file.
72 - 82 CENTER_LONGITUDE: the center longitude of the Sinusoidal
Equal-Area projection.
84 - 88 LINES: the number of lines in the image file. This
parameter specifies the number of elements of the
slowest varying dimension of the two dimensional image
array.
90 - 94 LINE_SAMPLES: the number of samples in the image file.
This parameter specifies the number of elements of the
fastest varying dimension of the two dimensional image
array.
96 - 99 MAP_RESOLUTION: the map resolution of the image file
expressed as number of pixels per degree at the equator.
102 - 108 VOLUME_ID 1: list of CDROM volume ID's on which the image
file
112 - 118 VOLUME_ID 2: is stored (VO_2001, VO_2002, etc.). There are
122 - 128 VOLUME_ID 3: seven fields in this list. Some image files
at
132 - 138 VOLUME_ID 4: 1/256 and 1/64 degrees per pixel exist on
more
142 - 148 VOLUME_ID 5: than one volume. The 1/4 and 1/16 degree
per pixel
152 - 158 VOLUME_ID 6: MDIM image files exist on all seven volumes.
162 - 168 VOLUME_ID 7:
171 - 181 X_AXIS_PROJECTION_OFFSET: the line position of line 1.0
and sample 1.0 in the x,y coordinates relative to the
origin of the map projection.
183 - 193 Y_AXIS_PROJECTION_OFFSET: the sample position of line 1.0,
sample 1.0 in the x,y coordinates relative to the
origin of the map projection.
196 - 271 NOTE: contains a brief description of the image file. The
field indicates the number of degrees/pixel of the file
and specifies the center latitude and longitude
coordinate of the image file.
275 - 282 IMAGE_ID: this field contains a six-character string to
identify the image file. The field matches the name
of the input file.
285 - 295 MAP_SCALE: this field gives the number of kilometers per
pixel at the equator.
298 - 303 SOURCE_IMAGE_ID 1: List of up to 20 source images. This
list
307 - 312 SOURCE_IMAGE_ID 2: contains the image identifiers of the
316 - 321 SOURCE_IMAGE_ID 3: Viking Orbiter images that were used
to
325 - 330 SOURCE_IMAGE_ID 4: create the MDIM image file. Blank
fields
334 - 339 SOURCE_IMAGE_ID 5: indicate no SOURCE_IMAGE_ID. There are
343 - 348 SOURCE_IMAGE_ID 6: never more than 20 images that make up
352 - 357 SOURCE_IMAGE_ID 7: an MDIM image file.
361 - 366 SOURCE_IMAGE_ID 8:
370 - 375 SOURCE_IMAGE_ID 9:
379 - 384 SOURCE_IMAGE_ID 10:
388 - 393 SOURCE_IMAGE_ID 11:
397 - 402 SOURCE_IMAGE_ID 12:
406 - 411 SOURCE_IMAGE_ID 13:
415 - 420 SOURCE_IMAGE_ID 14:
424 - 429 SOURCE_IMAGE_ID 15:
433 - 438 SOURCE_IMAGE_ID 16:
442 - 447 SOURCE_IMAGE_ID 17:
451 - 456 SOURCE_IMAGE_ID 18:
460 - 465 SOURCE_IMAGE_ID 19:
469 - 474 SOURCE_IMAGE_ID 20:
12 - GAZETTEER
Planetary nomenclature, like terrestrial nomenclature, is used to
uniquely identify a feature on the surface of a planet or satellite so
that the feature can be easily located, described, or discussed. The
gazetteer on the MDIM CDROM volume set contains detailed information
about all named features on Mars that the International Astronomical
Union (IAU) has named and approved from its founding in 1919 through its
triennial meeting in 1991.
The gazetteer is located on each CDROM volume of the seven volume set.
The information pertinent to the gazetteer is located in the GAZETTER
directory (a letter 'E' has been intentionally dropped from the spelling
of gazetteer because of the eight character limit on file names on
IBM/PC systems). In this directory, a detailed documentation of the
gazetteer can be found in the GAZETTER.TXT file. The file GAZETTER.TAB
is the gazetteer table. Each row in the table contains the description
of a single Martian feature. Finally, the GAZETTER.LBL file is the PDS
detached label that describes the file contents and format.
Ancillary files exist in the GAZETTER directory for users of the Word
Perfect text editor. The diacritical marks located in the gazetteer can
be converted to the Work Perfect format with the macros included in this
directory. Files which end in the extension *.WPM contain the Word
Perfect Macros. The document file WPMACRO.TXT describes the use of these
macros.
13 - ACKNOWLEDGEMENTS
The National Aeronautics and Space Administration is charged with the
responsibility for coordination of a program of systematic exploration
of the planets by U.S. spacecraft. To this end, it finances spaceflight
missions and data analysis and research programs administered and
performed by numerous institutions. The Geological Survey of the U.S.
Department of the Interior is the agency that performs most of the
mapping in support of NASA's program of planetary exploration and
scientific research.
The digital Mars maps contained in these volumes were compiled by the
U.S. Geological Survey (USGS) under funding provided by NASA through its
Geology and Geophysics Program at NASA headquarters, Washington, DC, and
through the Mars Observer Project administered by the Jet Propulsion
Laboratory, Pasadena, California. NASA's Planetary Data System provided
the guidance and standards required to manufacture and distribute the
optical disks containing this MDIM and DTM of Mars.
Compilation of the Mars digital models was performed at USGS under the
direction of R.M. Batson, L.A. Soderblom, and Sherman S.C. Wu, Principal
Investigator and Co-Investigators, respectively. Kathleen Edwards
provided the technical management and supervision of a team of 14
technicians who compiled the MDIM. The design, layout, and production of
the CDROMs was performed by E.M. Eliason and A. Manley at the USGS, and
M. Martin and J. Hyon at JPL
14 - REFERENCES
1. Snyder, C. W., 1977. The Missions of the Viking Orbiters, J.
Geophys. Res., 82, p. 3971-3983.
2. Snyder, C. W., 1979. The Extended Mission of Viking, J. Geophys.
Res., 84, p. 7917-7933.
3. Benesh, M., and T. Thorpe, 1976. Viking Orbiter 1975 visual
imaging subsystem calibration report, JPL Document 611-125, Jet
Propulsion Laboratory, Pasadena, Ca.
4. Klaasen, K. P., T. E. Thorpe, and L. A. Morabito, 1977. Inflight
performance of the Viking visual imaging subsystem, Applied
Optics, 16, p. 3158-3170.
5. Wellman, J. B., F. P. Landauer, D. D. Norris, and T. E. Thorpe,
The Viking Orbiter visual imaging subsystem, J. Spacecr.
Rockets, 13, p. 660-666, 1976.
6. Batson, R.M., 1987, Digital cartography of the planets: new
methods, its status, and its future: Photogrammetric
Engineering and Remote Sensing, vol. 53, no. 9, p. 1211-1218.
7. Batson, R.M., 1990, Cartography, in Greeley, Ronald, and Batson,
R.M., eds, Planetary Mapping: New York, Cambridge University
Press, p. 60-95.
8. Batson, R.M., 1990, Appendix I: Map formats and projections used
in planetary cartography, in Greeley, Ronald, and Batson, R.M.,
eds, Planetary Mapping: New York, Cambridge University Press,
p. 261-276.
9. Batson, R.M., 1990, Appendix III: Digital planetary cartography,
in Greeley, Ronald, and Batson, R.M., eds, Planetary Mapping: New
York, Cambridge University Press, p. 289-287.
10. Wu, S.S.C., and Schafer, F.J., 1984, Mars control network:
American Society of Photogrammetry, in Technical papers of the
50th annual meeting of the American Society of Photogrammetry,
vol. 2, Washington, D.C., March 11 - 16, 1984, p. 456-463.
11. Clark, David, 1923. Plane and geodetic surveying for engineers,
vol. 2, higher surveying [5th Ed., 1963, Revised by Clendinning,
James]. Constable & Co. Ltd., London, p. 599-600.
12. Johnson, T.V., L.A. Soderblom, J.A. Mosher, G.E. Danielson, A.F.
Cook, and P. Kupferman, 1983. Global multispectral mosaics of
the icy Galilean satellites. Journal of Geophysical Research,
vol. 88, no. B-7, p. 5789-5805.
13. Kieffer, H.H., P.A. Davis, and L.A. Soderblom, 1981. Mars' global
properties: Maps and applications. Proceedings of Lunar and
Planetary Science Conference XII, Houston, Texas, March 16-20,
1981, p. 1395-1417.
14. Pettengill, Gordon H., Donald B. Campbell, and Harold Masursky,
1980. The surface of Venus. Scientific American, vol. 243,
no. 2, p. 54-65.
15. Soderblom, L.A., Kathleen Edwards, E.M. Eliason, E.M. Sanchez,
and M.P. Charette, 1978. Global color variations on the Martian
surface. Icarus, vol. 34, p. 446-464.
16. Snyder, J. P., 1982. Map projections used by the U.S. Geological
Survey. Geological Survey Bulletin 1532, U.S. Government Printing
Office, Washington D.C., 313 p.
17. Planetary Cartography Working Group, 1984. Planetary cartography
in the next decade (1984-1994). National Aeronautics and Space
Administration Special Publication 475, 71 p.
18. LaVoie, S., C. Avis, H. Mortensen, C. Stanley, and L. Wainio,
1987. VICAR - User's Guide, JPL Document D-4186, Jet Propulsion
Laboratory, Pasadena, Ca.
19. Planetary Image Cartography System (PICS), Unpublished Manual,
Branch of Astrogeology, U. S. Geological Survey, Flagstaff, Az.,
1987. PICS is an integrated computerized system for the
systematic reduction, display, mapping, and analysis of
planetary image data.
20. Edwards, Kathleen, 1987, Geometric processing of digital images
of the planets: Photogrammetric Engineering and Remote
Sensing, vol. 53, no. 9, p. 1219-1222.
21. Wu, S.S.C., and Doyle, F.J., 1990, Topographic mapping, in
Greeley, Ronald, and Batson, R.M., eds, Planetary Mapping: New
York, Cambridge University Press, p. 169-207.
22. Bernstein, R., Branning, H., 2nd Ferneyhough, D.G., 1971,
Geometric and radiometric correction of high resolution images
by digital image processing techniques; IEEE Intl. Geosci.
Electronics Symp., Washington, D.C.
23. Davis, R. L., June 1990. Specification for the Object Description
Language, Version 2.0; Available from the PDS, Jet Propulsion
Laboratory, Pasadena, Ca.
24. Cribbs, M., and Wagner, D., May, 1991. Planetary Data System Data
Preparation Workbook; vols. 1 and 2, JPL Document 7669, Jet
Propulsion Laboratory, Pasadena, Ca.
25. VAX integers, as storage units in data files, are configured in
"least significant byte first" order. This is the order for
integer values used by VAX and IBM PC computer systems. Users
of other computer architectures (IBM Mainframes, Macintosh,
SUN, and Apollo) may need to swap the high and low byte
positions for 16-bit integer data. For 32-bit integer data,
swap byte pairs 1 and 4, and 2 and 3. For example, hexadecimal
value AA BB CC DD becomes DD CC BB AA.
26. Information processing -- Volume and file structure of CDROM for
information interchange, ISO/DIS document number 9660,
International Organization for Standardization, 1 Rue de
Varembe, Case Postale 56, CH-1121 Geneva 20, Switzerland, 1987.
27. McDonnell, M. J., 1981. Box-filtering Techniques: Computer Graphics and
Image Processing, Vol. 17, pp 65-70.
APPENDIX A - ISO VOLUME AND DIRECTORY STANDARD
A.1 - VOLUME AND DIRECTORY STRUCTURES
The volume and directory structure of the CDROM conforms to the standard
specified by the International Organization for Standardization (ISO)
[26]. This standard is known as the ISO-9660 standard. This CDROM disk
conforms to the first level of interchange, level-1.
A.2 - FILE STRUCTURE
The files on this CDROM are of two types: fixed-length record files,
and stream format files. The characteristics of each record type are
described in the following sections.
A.2.1 - FIXED LENGTH RECORDS
Records in a file with fixed-length records are all the same length, and
there is no embedded information to indicate the beginning or end of a
record. Fixed-length records allow any part of a file to be accessed
directly without the need to pass through the file sequentially. Image
files with the file name extension '.IMG' and table files with the file
name extension '.TAB' are fixed-length record files. The starting byte
of any record can be calculated as follows:
offset = (record-1)*length
where: offset = offset byte position of record from start of file
record = desired record to access
length = length of record in bytes
A.2.3 - STREAM FILES
Stream files typically are used to store ASCII text such as
documentation and program source code. A stream file may have records
of varying lengths. The end of a record is marked by two bytes
containing the ASCII carriage return and line feed characters (hex 0D
and 0A). Stream files are different from variable-length record files,
which store the record size in the first two bytes of each record.
On this CDROM, the documentation files, detached label files, and
software source code files are in stream format. They may be printed or
displayed on a terminal. Their file names have the extensions '.TXT',
'.LBL', '.C', or '.FOR'.
A.2.4 - EXTENDED ATTRIBUTE RECORD
An extended attribute record (XAR) contains information about a file's
record format, record attributes, and record length. The extended
attribute record is not considered part of the file and is not seen by
programs accessing a file with high-level I/O routines. Not all
computer operating systems support extended attribute records. Those
that do not will simply bypass the XAR when accessing a file.
APPENDIX B - SYNTACTIC RULES OF KEYWORD ASSIGNMENT STATEMENTS
The label area of the image files use the syntactic rules of the Object
Definition Language (ODL) adopted by the PDS. This appendix provides
only a very brief description of the syntax of the ODL language. For a
complete description of the ODL language see Davis [23], and the
Planetary Data System Data Preparation Workbook - Volume 1 [24].
A keyword assignment statement, made up of a string of ASCII characters,
contains the name of an attribute and the value of that attribute. A
keyword assignment statement has the general form shown below:
name = value [/* comment */]
The format of each keyword assignment statement is essentially
free-form; blanks and tabs are typically ignored by a parsing routine.
An attribute name is separated from its value by the equal symbol (=).
Each keyword assignment statement may optionally be followed by a
comment that more completely describes the entry. The comment begins
with a slash character followed by an asterisk character (/*), and
terminates with an asterisk character followed by a slash character
(*/). Comments may also exist on a line without a keyword assignment
statement. Note that the brackets indicate that the comment and its
delimiter are optional. The MDIM labels have carriage-return and
line-feed characters following the "name = value" sequence. The ODL
language does not require a cr/lf sequence at the end of each keyword
assignment statement but are optional in order to facilitate printing of
keywords.
Values associated with an attribute can be integers, real numbers,
unitized real numbers, literals, times, or text strings.
B.1 - INTEGER NUMBERS
An integer value consists of a string of digits preceded optionally by a
sign (+ or -). Non-decimal based integers are expressed according to the
Ada language convention: b#nnnnnnn#, where 'b' represents the base of
the number, and '#' delimits the number 'nnnnnnnn'. For example, the
number expressed as 2#111# represents the binary number 111, which is 7
in base 10.
B.2 - REAL NUMBERS
A real number has the form: [s]f.d[En] where:
s = optional sign (+ or -)
f = one or more digits that specify the integral portion of the
number.
d = one or more digits that specify the fraction portion of the
number.
n = an optional exponent expressed as a power of 10.
A unitized real number is a real number with an associated unit of
measurement. The units for a real number value are enclosed in angle
brackets (< >). For example, 1.234 <SECONDS> indicates a value of 1.234
seconds.
B.3 - DATES AND TIMES
A special form of a numeric field is a time value. The following format
of date/time representations is used:
yyyy-mm-ddThh:mm:ss.fffZ
where: yyyy = year
mm = month
dd = day of month
hh = hour
mm = minute
ss = seconds
fff = fraction of a second
Z = The Z qualifier indicates the time is expressed
as Universal Time Corrected (UTC).
B.4 - LITERAL VALUES
A literal value is an alphanumeric string that is a member of a set of
finite values. It can also contain underscore character (_). A literal
value must be delimited by double or single quote characters (" or ') if
it does not begin with a letter (A-Z). If the literal begins with a
letter, it does not have to be enclosed in single quotes. If a literal
appears within quotes, the literal may contain any printable ASCII
character. For example, the literal value "1:1" is legal as long as the
single or double quoted format is used. A keyword assignment statement
using a literal value might look like the examples shown below:
DATA_SET_ID = "VO1/VO2-M-VIS-5-DIM-V1.0"
TARGET_NAME = MARS
B.5 - TEXT CHARACTER STRINGS
Text strings can be any length and can consist of any sequence of
printable ASCII characters including tabs, blanks, carriage-control, or
line-feed characters. Text strings are enclosed in double quote
characters. If the text string comprises several lines, it continues
until a double quote character is encountered and includes the carriage-
control and line-feed characters.
APPENDIX C - KEYWORD ASSIGNMENTS FOR MDIM IMAGES
CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL
This keyword provides a mechanism for image files on this CDROM to
conform to the SFDU (Standard Formatted Data Unit) convention.
The first 20 bytes identify the file as a CCSDS SFDU entity. The
next 20 bytes identify the file as a registered product of the
JPL SFDU control authority. The components of both SFDU labels
are the control authority identifier (characters 1-4), the
version identifier (character 5), the class identifier (character
6), a spare field (characters 7-8), a format identifier
(characters 9-12), and a length field indicator (characters
13-20). The version identifier indicates a "Version-3" label,
which allows files to be delimited by an end-of-file marker,
rather than requiring a byte count to be embedded in the label.
The keyword conforms to standard PDS keyword syntax and the value
associated with this keyword will always be SFDU_LABEL.
RECORD_TYPE = FIXED_LENGTH
This keyword defines the record structure of the file. The MDIM
image files are always fixed-length record files. This keyword
always contains the value FIXED_LENGTH.
RECORD_BYTES = xxxx
Record length in bytes for fixed length records.
FILE_RECORDS = xxxx
Total number of records contained in the file.
LABEL_RECORDS = xxxx
Number of records in the label area of the image file.
^IMAGE_HISTOGRAM = xx
The (^) character prefixing a keyword indicates that the keyword is
a pointer to the starting record of a data object in the file. In
this case, the keyword is the pointer to the Image Histogram Object.
The keyword value indicates the starting record in the file for the
Image Histogram Object. The number of records found in an object is
determined by differencing the value of the pointer keyword from the
value of the next pointer.
^IMAGE = xx
The keyword value points to the starting fixed-length record in
the file for the Image Object.
DATA_SET_ID = "VO1/VO2-M-VIS-5-DIM-V1.0"
The PDS defined data set identifier for the MDIM image data
products produced from the Viking Orbiter Imaging System.
SPACECRAFT_NAME = {VIKING_ORBITER_1, VIKING_ORBITER_2}
The spacecraft name identifies the spacecrafts that acquired the
image data. For the MDIM images, this keyword always contains the
values VIKING_ORBITER_1 and VIKING_ORBITER_2 to indicate that
images that make up the mosaics are a composite of data acquired
from these two spacecraft.
TARGET_NAME = MARS
Observation target of the image. This value is always MARS for the
MDIM digital image products.
IMAGE_ID = vwxxyzzz
This is the unique image identification code for the MDIM image. The
IMAGE_ID is the same as the name given to the file.
v = Type of image file
M - Mars Digital Image Map
T - Mars Digital Topographic Model
S - Shaded Relief Airbrush Map
w = Resolution code for image file
C - 1/4 degrees/pixel
E - 1/16 degrees/pixel
G - 1/64 degrees/pixel
I - 1/256 degrees/pixel
xx = Central latitude value rounded
down to nearest whole latitude
y = North or South latitude
N - North latitude
S - South latitude
zzz = Central longitude value rounded
down to nearest whole longitude
SOURCE_IMAGE_ID = {"316A27","427A33"}
The MDIM images are a mosaic of Viking Orbiter images. This keyword
lists the IMAGE_ID's of those Viking Orbiter images that were
used in the mosaic for this image. This keyword is a set of
literal values.
INSTRUMENT_NAME = {VISUAL_IMAGING_SUBSYSTEM_CAMERA_A,
VISUAL_IMAGING_SUBSYSTEM_CAMERA_B}
The name of the cameras used to acquire the image. This keyword
will always contain the values VISUAL_IMAGING_SUBSYSTEM_CAMERA_A
and _B.
NOTE = "description"
This field provides the product name, scale, and latitude and
longitude of the center of the image.
OBJECT = IMAGE_HISTOGRAM
ITEMS = 256
ITEM_TYPE = VAX_INTEGER
ITEM_BITS = 32
END_OBJECT = IMAGE_HISTOGRAM
This keyword sequence identifies the Image Histogram Object. The
object contains 256 elements, stored in VAX integer format [22].
Each element has 32 bits. The records associated with an object are
concatenated together to make the object. Some objects do not
completely fill the records that make up the object.
OBJECT = IMAGE
LINES = xxxx
LINE_SAMPLES = xxxx
SAMPLE_TYPE = UNSIGNED_INTEGER
SAMPLE_BITS = 8
SAMPLE_BIT_MASK = 2#11111111#
CHECKSUM = xxxxxxxxx
END_OBJECT = IMAGE
This keyword sequence describes the image object. The meaning of
the keywords with this sequence area as follows:
LINES = xxxx
Number of image lines in the image object.
LINE_SAMPLES = xxxx
Number of samples in each image line.
SAMPLE_TYPE = UNSIGNED_INTEGER
Data type for pixels values, should always be unsigned
integers. For DTM images the value is SIGNED_INTEGER
SAMPLE_BITS = 8
Number of bits in a pixel, which are 8-bit values in the
range 0 to 255. For DTM images the value is 16
SAMPLE_BIT_MASK = 2#11111111#
Active bits in an image sample. The number is expressed as a
base 2 value in the Ada language number base convention. The
keyword value consists of a string of 1's or 0's. The value
1 indicates a bit is active and a 0 indicates a bit is not in
use. For example, SAMPLE_BIT_MASK = 2#11111111# indicates
all bits active.
CHECKSUM = xxxxxxxxxx
The sum of all the pixel values within the image. This
parameter can be used to verify the reading of an image file.
OBJECT = IMAGE_MAP_PROJECTION_CATALOG
^DATA_SET_MAP_PROJECTION_CATALOG = "DSMAPDIM.LBL"
MAP_PROJECTION_TYPE = SINUSOIDAL
MAP_RESOLUTION = x<PIXEL/DEG>
MAP_SCALE = x.xxxxx<KM/PIXEL>
MAXIMUM_LATITUDE = x.xxxxx
MINIMUM_LATITUDE = x.xxxxx
MAXIMUM_LONGITUDE = x.xxxxx
MINIMUM_LONGITUDE = x.xxxxx
X_AXIS_PROJECTION_OFFSET = x.xxxxx
Y_AXIS_PROJECTION_OFFSET = x.xxxxx
A_AXIS_RADIUS = 3393.40
B_AXIS_RADIUS = 3393.40
C_AXIS_RADIUS = 3375.73
FIRST_STANDARD_PARALLEL = "N/A"
SECOND_STANDARD_PARALLEL = "N/A"
POSITIVE_LONGITUDE_DIRECTION = WEST
CENTER_LATITUDE = 0.00000
CENTER_LONGITUDE = x.xxxxx
REFERENCE_LATITUDE = "N/A"
REFERENCE_LONGITUDE = "N/A"
X_AXIS_FIRST_PIXEL = 1
Y_AXIS_FIRST_PIXEL = 1
X_AXIS_LAST_PIXEL = xxxx
Y_AXIS_LAST_PIXEL = xxxx
MAP_PROJECTION_ROTATION = "N/A"
END_OBJECT = IMAGE_MAP_PROJECTION_CATALOG
This keyword sequence describes the cartographic keywords that
define the mapping parameters of the image.
^DATA_SET_MAP_PROJECTION_CATALOG = "DSMAPDIM.LBL"
This keyword points to a separate file (DSMAPDIM.LBL) on
the CDROM that contains supplemental and nonessential
keyword descriptors for map projection parameters. By
convention, supplemental labels are found in the LABEL
directory.
MAP_PROJECTION_TYPE = SINUSOIDAL
This element identifies the type of projection used in the
map. This value is always SINUSOIDAL for the MDIM products
and signifies a Sinusoidal Equal-Area projection.
MAP_RESOLUTION = x<PIXEL/DEG>
This element identifies the scale of the MDIM image file. The
resolution is defined in pixels per degree.
MAP_SCALE = x.xxxxx<KM/PIXEL>
This element identifies the scale of the MDIM image file
and is defined in kilometers per pixel.
MAXIMUM_LATITUDE = x.xxxxx
This element specifies the northern most latitude in the MDIM
image file.
MINIMUM_LATITUDE = x.xxxxx
This element specifies the southern most latitude in the MDIM
image file.
MAXIMUM_LONGITUDE = x.xxxxx
This element specifies the left-most longitude of the image
file.
MINIMUM_LONGITUDE = x.xxxxx
This element specifies the right-most longitude of the image
file.
X_AXIS_PROJECTION_OFFSET = x.xxxxx
This element provides the line offset value of the map
projection origin position from line and sample 1,1. Note
that the positive direction is to the right and down. See
Appendix E for the use of this element.
Y_AXIS_PROJECTION_OFFSET = x.xxxxx
This element provides the sample offset value of the map
projection origin position from line and sample 1,1. Note
that the positive direction is to the right and down. See
Appendix E for the use of this element.
A_AXIS_RADIUS = 3393.40
B_AXIS_RADIUS = 3393.40
C_AXIS_RADIUS = 3375.73
These elements provide the semi-major axis (A), intermediate
axis (B), and semi-minor axis of the ellipsoid that defines
the shape of the body defined in kilometers. These values
are always 3393.40, 3393.40, and 3375.73 respectively.
FIRST_STANDARD_PARALLEL = "N/A"
This element is a mapping transformation parameter. The
Sinusoidal Equal-Area projection does not used this element.
SECOND_STANDARD_PARALLEL = "N/A"
This element is a mapping transformation parameter. The
Sinusoidal Equal-Area projection does not used this element.
POSITIVE_LONGITUDE_DIRECTION = WEST
This element identifies the direction of longitude
(EAST,WEST) for a planet. The IAU definition for direction
of positive longitude is adopted. For MARS this direction
is WEST.
CENTER_LATITUDE = 0.00000
This element identifies the center latitude of the
projection. For Sinusoidal Equal-Area projections, this
value is zero.
CENTER_LONGITUDE = x.xxxxx
This element identifies the center longitude of the
projection. Each MDIM image file has its own center
longitude. See Appendix E for the use of this mapping
parameter.
REFERENCE_LATITUDE = "N/A"
This element is a mapping transformation parameter. The
Sinusoidal Equal-Area projection does not used this element.
REFERENCE_LONGITUDE = "N/A"
This element is a mapping transformation parameter. The
Sinusoidal Equal-Area projection does not used this element.
X_AXIS_FIRST_PIXEL = 1
This element provides the x-dimension index to be assigned
the first pixel that was physically recorded at the
beginning of the image array. This value always 1 for MDIM
image files.
Y_AXIS_FIRST_PIXEL = 1
This element provides the y-dimension index to be assigned
the first pixel that was physically recorded at the
beginning of the image array. This value always 1 for MDIM
image files.
X_AXIS_LAST_PIXEL = xxxx
This element provides the x-dimension index to be assigned
the last pixel that was physically recorded at the end of
the image array. For MDIM image files, this element equals
the number of lines in the image.
Y_AXIS_LAST_PIXEL = xxxx
This element provides the y-dimension index to be assigned
the last pixel that is physically recorded at the end of
the image array. For MDIM image files, this element equals
the number of samples in the image.
MAP_PROJECTION_ROTATION = "N/A"
This element is a mapping transformation parameter. The
Sinusoidal Equal-Area projection does not used this element.
END
The keyword entries with a line that contains only the word
END. Bytes in the label area after the END statement are ignored.
APPENDIX D - GEOMETRIC DEFINITION OF A PIXEL
The purpose here is to describe the spatial or geometric definition of a
pixel used in the generation and utilization of the MDIM digital image
products. A broad range of factors enters into this question. For
example, is a pixel to be conceived of as a point or as an area? The
point definition would be most convenient, for instance, when dealing
with coordinate grid overlays. This results in an odd number of pixels
across a map that has an even number of spatial increments. For
changing scales (for instance by even powers of 2) this definition
becomes a problem. In this case it makes more sense to treat a pixel as
a finite area. Then an even number of pixels covers an even number of
spatial increments and decreasing/increasing scales by a power of 2
becomes trivial. However, grids now fall between pixels, at least in a
mathematical sense. Their treatment in the generation of hardcopy
therefore becomes an issue.
It was decided that the area concept of a pixel was the better choice;
we would have to live with the asymmetries introduced in things like
cartographic grids. There are various solutions: (1) use two pixels for
the width of a grid line, (2) stagger grid pixels back-and-forth across
the mathematical position, (3) use a convention whereby grid lines are
systematically drawn offset from their mathematical position.
The next issue is the conversion between integer coordinates and real
coordinates of the pixel mesh. We adopt the convention that pixels are
numbered (or named if you like) beginning in the upper left corner with
line 1, sample 1 (pixel 1,1); lines increase downward; samples increase
to the right. (Even this is not a universal standard; some astronomical
systems begin, perhaps more logically, in the lower left corner.) There
are three reasonable possibilities for aligning a real, or floating
point, coordinate system with the pixel mesh: the coordinate 1.0, 1.0
could be the upper left, the center, or the lower right of pixel 1,1.
The convention historically used for geometric calibration files (reseau
positions) and also used in the Multimission Image Processing Laboratory
at the Jet Propulsion Laboratory, is that the center of the pixel is
defined as its location in real coordinates. In other words, the real
coordinates of the center of pixel 1,1 are 1.0, 1.0. The top left corner
of the pixel is .5, .5 and the bottom right corner is 1.49999...,
1.499999. The bottom and right edge of a pixel is the mathematically
open boundary. This is the standard adopted in the MDIM image products.
Cartographic conventions must also be defined. The map projection
representation of a pixel is mathematically open at the increasing
(right and lower) boundaries, and mathematically closed at its left and
upper boundaries. An exception occurs at the physical limits of the
projection; the lower boundary of the lowest pixel is closed to include
the limit of the projection (e. g. the south pole). Figure D.1 shows
the coordinates of Pixel 1,1.
Figure D.1 - Coordinates of Pixel 1,1
longitude 180.0 179.00001
| |
latitude | | line
90.0 -- ----------------- -- .5
| |
| |
| |
| |
| + |
| (1.0,1.0) |
| |
| |
| |
89.00001 -- ----------------- -- 1.49999
| |
| |
sample .5 1.49999
Finally, we must select a convention for drawing grid lines for various
cartographic coordinates on planetary images and maps. The convention
used for MDIM image products is that a grid line is drawn in the pixels
that contain its floating point value until the open boundary is reached
and then an exception is made so that the outer range of latitude and
longitude will always appear on the image. This means, in the example
given above, a 10 degree grid would start on pixel 1 and be drawn on
every tenth pixel (11,21,31,...) until the open boundary is reached.
Then the line would be drawn on the pixel previous to the open boundary
(line 180 instead of line 181, or sample 360 instead of 361).
To summarize, the MDIM conventions are:
1) Pixels are treated as areas, not as points.
2) The integer coordinates begin with 1,1 (read "line 1, sample 1")
for the upper-left-most pixel; lines increase downward; samples
increase to the right.
3) Integer and floating point image coordinates are the same at the
center of a pixel.
4) Grids will be drawn in the pixels that contain the floating point
location of the grid lines except for open boundaries, which will
be drawn to the left or above the open boundary.
APPENDIX E - SINUSOIDAL EQUAL-AREA PROJECTION EQUATION
MDIM's are presented in a Sinusoidal Equal-area map projection. In this
projection, parallels of latitude are straight lines, with constant
distances between equal latitude intervals. Lines of constant longitude
on either side of the projection meridian are curved since longitude
intervals decrease with the cosine of latitude to account for their
convergence toward the poles. This projection offers a number of
advantages for storing and managing global digital data; in particular,
it is computationally simple, and data are stored in a compact form.
The Sinusoidal Equal-area projection is characterized by a projection
longitude, which is the center meridian of the projection, and a scale,
which is given in units of pixels/degree. The center latitude for all
MDIM's is the equator. Each MDIM file contains its own central meridian.
The transformation from latitude and longitude to line and sample for
planets with a direction of positive longitude of WEST is given by the
following equations:
line = INT(X_AXIS_PROJECTION_OFFSET - lat*MAP_RESOLUTION + 1.0)
sample = INT(Y_AXIS_PROJECTION_OFFSET - (lon - CENTER_LONGITUDE)*
MAP_RESOLUTION*cos(lat) + 1.0)
Note that integral values of line and sample correspond to center of
a pixel. Lat and lon are the latitude and longitude of a given spot
on the surface.
INT is the fortran equivalent floating point to integer function. This
function converts floating point values to integer by truncation of the
fractional part of the floating point value.
X_AXIS_PROJECTION_OFFSET is the line number minus one on which the map
projection origin occurs. The map projection origin is the intersection
of the equator and the projection longitude. The value of
X_AXIS_PROJECTION_OFFSET is positive for images starting north of the
equator and is negative for images starting south of the equator. The
X_AXIS_PROJECTION_OFFSET is found in the labels of each image file.
Y_AXIS_PROJECTION_OFFSET is the nearest sample number to the left of the
projection longitude. The value of Y_AXIS_PROJECTION_OFFSET is positive
for images starting to the west of the projection longitude and is
negative for images starting to the east of the projection longitude.
The Y_AXIS_PROJECTION_OFFSET is found in the labels of each image file.
CENTER_LONGITUDE is the value of the projection longitude, which is the
longitude that passes through the center of the projection. The
CENTER_LONGITUDE is found in the labels of each image file.
MAP_RESOLUTION is the number of pixels per degree on the planet. The
values for MDIM products will be 256, 64, 16, and 4. The MAP_RESOLUTION
is found in the labels of each image file.
There are four PDS parameters that specify the latitude and longitude
boundaries of an image. MAXIMUM_LATITUDE and MINIMUM_LATITUDE specify
the latitude boundaries of the image, and MAXIMUM_LONGITUDE and
MINIMUM_LONGITUDE specify the longitudinal boundaries of the map.
A special note is required for the MAXIMUM_LONGITUDE and
MINIMUM_LONGITUDE parameters that define the boundaries of an image. The
MAXIMUM_LONGITUDE will be greater than the MINIMUM_LONGITUDE except when
the image map crosses the zero meridian. When the zero meridian is
contained in the image area, then the MINIMUM_LONGITUDE will be greater
than the MAXIMUM_LONGITUDE. When this occurs, it may be convenient for a
computer algorithm that uses these parameters to subtract 360.0 degrees
from the MINIMUM_LONGITUDE. For example, if an image had longitude
boundary limits from 10.0 degrees longitude (MAXIMUM_LONGITUDE) to 350.0
degrees longitude (MINIMUM_LONGITUDE) then it is implied that the zero
meridian is in the middle of the image file. One could think of the
longitude limits of the file going from 10.0 to -10.0 degrees longitude.
For global maps that cover the entire 360 degrees of a planet, the
MINIMUM_LONGITUDE will equal the MAXIMUM_LONGITUDE indicating that the
"left" edge of the map has the same longitude as the "right" edge of the
map.
